1. Field of the Invention
The present invention is related to allocating resources amongst multiple computers and more particularly to managing and allocating resources for cloud computing.
2. Background Description
Recently, cloud computing has offered great opportunities for a broad range of applications. Cloud service providers (e.g., with mainframe computers), users/clients connected together over networks constitute a client-cloud system wherein the cloud computers provide services and resources and handle data-intensive computing tasks for the clients. This has allowed user clients to become much more lightweight and mobile, while still to having require access to resources managed by the resource providers.
Typically, users may request allocation of available resource capacity from one or more providers simultaneously or essentially simultaneously, i.e. within a given time interval. A typical state of the art resource protocol for allocating resources has two phases: the selection phase where the user selects available resources; and, the confirmation or commit phase, the user confirms the resource allocation. The selection phase is first come, first served. So, when multiple users select (request) the same resource(s), the first user who commits the selection receives the resource i.e., confirms. Frequently, however, there is a delay between selecting/requesting a resource or resources and confirmation/commit that causes a conflict. Conflicts arise because during that delay resource availability information may become stale. This can result in what is known as deadlock and/or livelock.
Deadlock occurs when a user with a committed resource (locked) is waiting for another requested resource, e.g., where the other resource is committed to another user and the first user is waiting for that committed resource to become available. Deadlocks can be avoided by refusing to allocate less than all of the requested resources or services, i.e., all or nothing.
Livelock occurs when multiple users requesting multiple resources are each granted access to some, but not all of the requested resources. In a sort of round robin game of resource tag, while one user is deciding to commit desired capacity, some or all of that desired capacity can be allocated elsewhere. So, to avoid having capacity allocated elsewhere, the user may have to hurry decisions after selecting resources. Otherwise, with the requested capacity allocated elsewhere, the user may take several iterations (messages with the providers) negotiating to recover from stale information. Consequently, the negotiation messages can waste valuable computing time and resources, and therefore, may be expensive.
State of the art approaches for reducing the number of messages required by negotiations include Order-based Deadlock Prevention Protocols (ODP2) and back-off mechanisms. Examples of these approaches are described by Jardine et al. “Livelock avoidance for meta-schedulers,” Proceedings of International Symposium on High performance Distributed Computing. (2001); and by Hah et al., “A SNAP-based community resource broker using a three-phase commit protocol: a performance study,” The Computer Journal (2005). These state of the art approaches do not make users aware of any other users that may be concurrently negotiating for the same resources. Instead, only when allocation fails do users receive messages that indicate committing the request failed. Consequently, these state of the art negotiations require several messages and allow users too little time to make allocation decisions.
Thus, there is a need for a reducing negotiations required in allocating resources to users and more particularly in facilitating resource allocation with minimal conflicts, without rushing user decisions.